\section{Concurrency}
Erlang's approach to concurrency is based on the Actor Model of computation, that treats "actors" as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received \cite{wikiactors}. Erlang's processes are the actors that communicate using message passing. 

\subsection{Processes:}
Erlang's processes are VM level processes, also known as "green threads" that do not map to system level processes or threads. Typically the Erlang VM creates 2 threads per core, one for I/O and the other running the process scheduler. Erlang's processes have the following features:
\begin{enumerate}
\item \textbf{Small overhead} -  The size of a Process Control Block(PCB) is only 300 bytes, which makes it light in comparison to 1024 bytes PCB of a Unix process. The small overhead is essential for an Erlang process as the concurrency model supported by Erlang typically demands the creation of a huge no. of processes. Fig~\ref{fig:PCB} shows some important fields of an Erlang PCB.
\item \textbf{Independent Memory} - Each Erlang process has its own stack and heap. No memory sharing occurs between processes. Hence the PCB of each process has heap and stack pointers. This scheme although high on memory usage, prevents memory corruption by one process from cascading into system memory corruption. This is extremely important for Erlang's fault tolerant requirement.
\item \textbf{Garbage Collection} - Since Erlang's processes do not share a common heap, the garbage collection is on a per process basis and is performed by the process itself. This allows Erlang to guarantee a \textit{Soft Real Time} behavior as no other process is affected by the memory utilization pattern of an unrelated process.
\end{enumerate}
\begin{figure*}[t]
\begin{minipage}[t]{\columnwidth}
\centering
\psfig{figure=figures/PCB.pdf,width=2in,height=3in}
\caption{Process Control Block for Erlang process}
\label{fig:PCB}
\end{minipage}
\hfill
\end{figure*}
\subsubsection{A comparison of Erlang's processes and Java Threads}
Threads in Java are also green threads, i.e. they are created and scheduled inside the VM. Although some of the current Java implementation do create one system thread per Java thread, this is not a VM requirement. Table~\ref{table:comparison} demonstrates the creation times of various no. of concurrent processes and threads in case of Erlang and Java respectively. Number of messages shown in the table are only relevant to Erlang and are used to highlight the message passing overhead which erlang will have in order to achieve concurrency.
\begin{table} 
\caption{Process creation time}
\centering
\begin{tabular*}{0.815\textwidth}{ || c | c | c | c || }
  \hline\hline
  No. of Processes & No. of Messages & Java(time in msecs) & Erlang(time in msecs) \\
  \hline\hline 
    1000 & 100	& 132 & 67\\
  \hline 
2000 & 100 & 328 & 83\\
  \hline 
3000 & 100 & 661 & 125\\
  \hline 
4000 & 100 & 873 & 182\\
  \hline 
5000 & 100 & 1294 & 207\\
  \hline 
6000 & 100 & 1950 & 261\\
  \hline 
7000 & 100 & OutOfMemoryError & 319\\
  \hline 
10000 & 100 & OutOfMemoryError & 420\\
  \hline 
15000 & 100 & OutOfMemoryError	& 620\\
  \hline 
20000 & 100 & OutOfMemoryError & 832\\
  \hline 
30000 & 100 & OutOfMemoryError & 1254\\
  \hline\hline
\end{tabular*}
\label{table:comparison}
\end{table}

\subsection{Message Passing}
Message passing involves 2 processes, a sender and a receiver. The sending process first copies the message into a buffer from where it is copied into the heap of the receiving process. Each process has a queue of messages which have been sent to it and are waiting to be processed. This queue is maintained as a list on the heap of each process. After the message has been copied to the receiving process, the message is linked onto the end of the list by copying the pointer of the heap location to the message queue. If the receiving process is currently in the suspended state sender's action also involves waking up the process and adding it to the scheduled queue. 
\subsection{Concurrency Primitives}
In order to implement the message passing paradigm, Erlang provides three concurrency primitives:
\begin{itemize}
\item \textbf{Spawn(M, F, [A1, A2, ..., An]):} creates a new \emph{\textit{parallel}} process. This process evaluates the function F in module M with arguments A1, A2...An. 
Example: \\\textbf{Pid = spawn(fun() -$>$ wait()  end).}
\item \textbf{Send a Message:} \textit{Pid ! Msg}. Sends a message (value of variable Msg) to process (Pid) asynchronously. 
\item\textbf{Receive a message:} On receiving a message(msg) an action is taken by the process.\\\textbf{
\hspace*{1in}receive\\
\hspace*{1.5in}\{msg\} -$>$ action()\\
\hspace*{1in}end.}\\
The receiver can filter which messages it wants to process. This is implemented by pattern matching. In the above example the function action() is called only for messages that match the pattern \{msg\}. Delivered messages are kept in a message queue and are not removed until they match the receiver's message pattern. When a process enters a receive, it gets suspended unless there is a message to be processed. 
Example:\\\textbf{
\hspace*{1in}receive\\
\hspace*{1.5in}$<$pattern 1$>$ [when $<$guard 1$>$] -$>$\\
\hspace*{2in}$<$action 1$>$;\\
\hspace*{1.5in}...\\
\hspace*{1.5in}$<$pattern N$>$ [when $<$guard N$>$] -$>$\\
\hspace*{2in}$<$action N$>$;\\
\hspace*{1in}$[$after $<$timeout-expression$>$ -$>$ \\
\hspace*{1.5in}$<$timeout-actions$>$$]$\\
\hspace*{1in}end}\\
As the receiving process has to block until a message that matches the pattern becomes available in the queue, it may have to block indefinitely. In order to provide stricter guarantees of time for message receiving process, a timeout construct is provided. Erlang process waits for the timeout value(msecs) and expires if the message does not arrive for timeout value. The timeout is implemented by a scheduled system interrupts causing a global value to be implemented in the Erlang runtime, which then uses this global value to wake up processes that may have timed out on a receive.
\end{itemize}

\subsection{Process Scheduling:}
Process Scheduling in Erlang is based on 4 different queues. The queues are max, high, normal and low in the order of decreasing priority. Each process can be assigned a queue and scheduling in each queue is in round robin fashion. Amongst the different queues the highest priority queue i.e. the max queue is emptied of all the processes first. This is where the processes with stricter real time requirements get scheduled. After that the high priority queue gets evaluated. Processes from normal and low queue are processed differently. Eight reductions(function calls) are performed in the normal queue and then one reduction is performed in the low queue. 


